home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_1599 / 1560 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  3.6 KB

  1. Date: Mon, 13 Jun 94 01:45 CDT
  2. From: ekl@sdf.lonestar.org (Evan K. Langlois)
  3. To: mint@atari.archive.umich.edu
  4. Subject: TOSWIn again.
  5.  
  6.  
  7. Well, I have messed about with TOSWIN alot trying to find the leak.
  8. I even tried using GDB (and found that I couldn't get any symbol table
  9. information out of it, althoughit should have worked, and it looked like
  10. it worked, but it kept saying something about the symbol size being out
  11. of range or something like that - anyone use GDB??)
  12.  
  13. Anyway, best I can tell you is that every window that opens uses an EXACT
  14. amount of memory every time a new window opens.  Every time TOSWIN opens
  15. a new window 29216 bytes are lost to the system.  MiNT eats it.  I couldn't
  16. find any blocks of that size allocated in the system.  Since I don't use
  17. RUNTOS, but my own program that searches PATH and such, running a program
  18. in a window is just as easy as running it from a shell (so instead of
  19. "vi myfile.c" , I type "ts vi myfile.c" and get a new window, with all the
  20. current directories staying teh same, and ts finds vi and passes args).
  21. Anyway, because of this, its more convienient to always keep the shell free
  22. to run something else, so I'm always running a new window for every 
  23. program I run - even archivers, less, or whatever.  Its rare that I use
  24. the shell directly unless its something that just runs once, like PS.
  25. So, since I continuously open and close windows on my system, the system
  26. will just throw away memory at an alarming rate.  10 windows is easy to
  27. go through in an hour or less, and there is 292K of memory gone.  In
  28. a few hours I gotta reboot because 4MB won't stretch far enough when
  29. MiNT eats over 2MB.   I noticed that TOSWIN says nalloc out of memory
  30. (in debugger) when it opens a window, and so I have a feeling that it
  31. could be related to nalloc().  But .. why 29216 bytes???   Does that
  32. sound like any sort of blocksize to anyone?   It doesn't ring a bell
  33. here .. I'm baffled!
  34.  
  35. Oh .. fasttext is still screwed.  My cursor is gone.  I can't get it
  36. to stay on.  It goes away when I press a key.   Any fix?
  37.  
  38. It doesn't come back 'til I press RETURN
  39.  
  40. And then only sometimes (yes the crazy spacing is try and make my cursor
  41. come back .. so I make lots of blank lines!!)
  42.  
  43. Also, tfork'd processes seem to be a bit unstable.  My terminal didn't
  44. cause any problems before, and now if I run BASH from it, and then type
  45. EXIT, the whole system locks up.  I used to get my terminal back!
  46. And TOSWIN can't change the window size of the window my terminal
  47. runs in.  If I try, the whole system locks up.  It didn't do this
  48. before (not sure exactly which patches/versions this started on, but 1.09
  49. was just fine with the terminal).
  50.  
  51. Oh ... bug in defrag for minix!!!!   It does NOT recognize the new 
  52. symbolic link format and leaves the links pointing to nothing, so the
  53. file system treats them as the "." directory.  Using "rm" to remove the
  54. link and then making a new one works, but dragging it away with GEM just
  55. causes MiNT to nest into folders until it gives an error.  The link just
  56. nests into itself.   It was a pain setting all the symbolic links over
  57. again, but it works.   FSCK would not fix this!!  I wish it would have!
  58.  
  59. Sometimes killing FSCK (I run it from MiNT.CNF before GEM runs) will stop
  60. GEM from working.  GEM crashes shortly after an exception 10, which is
  61. GEM using the LineA to turn off the mouse (or on or something else really
  62. stupid with LineA).  If I let fsck run, GEM works, if I kill fsck early,
  63. then GEM crashes.   Can someone tell me what these have to do with each
  64. other???
  65.  
  66. MiNT's LineA handling is still pretty poor it seems.  LineA graphics have
  67. never worked right under MiNT for some reason.
  68.  
  69.